Data communication in a computer network involves the exchange of data between two or more entities interconnected by communication links, segments and sub-networks. These entities are typically software processes executing on hardware computer platforms, such as end nodes and intermediate nodes. Communication software executing on the end nodes correlate and manage data communication with other end nodes. The nodes typically communicate by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP).
An intermediate node, such as a router, may interconnect the subnetworks to extend the effective “size” of the computer network. The router executes routing protocols used to direct the transmission of data traffic between the end nodes, such as hosts. Typically, the router directs network traffic based on destination address prefixes contained in the packets, i.e., the portions of destination addresses used by the routing protocol to render routing (“next hop”) decisions. Examples of such destination addresses include Internet Protocol (IP) version 4 (IPv4) and version 6 (IPv6) addresses. A prefix implies a combination of an IP address and a mask that cooperate to describe an area or range of the network that a router can reach.
Unicast data transfer involves forwarding a data packet from a single sending process of an end node (“source”) to a single receiving process of an end node (“receiver”) on the computer network. Often the destination of the data packet issued by a source may be more than one, but less than all of the receivers on the network. This type of multicast data transfer is typically employed to segregate communication between groups of receivers on the network. IP multicasting, in particular, may be used to disseminate data to a large group of receivers on the network.
To affect IP multicasting, the source generally specifies a destination IP address that is a multicast group address for the message and, as such, can only represent receivers of packets. The IPv4 (or IPv6) address range is subdivided into different prefixes, one of which is designated for use by IP multicast. Receivers typically notify their communication software of their desire to receive messages destined for the multicast group address; this is called “joining a multicast group”. These receiving members then “listen” on the multicast address and, when a multicast message is received at a receiver, it delivers a copy of the message to each process that belongs to the group.
IP multicasting relies on (i) a group management protocol to establish and maintain local multicast group membership, and (ii) multicast routing protocols to route packets efficiently. The Internet Group Membership Protocol (IGMP) manages packet communication between hosts and their local multicast router, letting them join or leave groups. That is, IGMP is used to send a group membership message from a host to its directly connected (“last-hop”) router, indicating that the host wants to join a group (address) as a receiver. Note that IGMP is an IPv4 group membership protocol; the conventional Multicast Listener Discovery (MLD) protocol is substantially similar to, and performs the same functions as, IGMP, but for IPv6. When group membership is established, multicast packets (identified by a multicast group address in the destination address field of an IP header) are forwarded between routers using multicast routing protocols.
Multicast routing protocols construct distribution trees through the network and direct multicast forwarding. The multicast distribution trees define the path that multicast traffic will take through the network to group members. These paths are based on source or shared multicast distribution trees. A multicast distribution tree is shared when any source (host) originating data traffic destined to a group address of a multicast group uses the same distribution tree to forward data to the receivers. In contrast, a source distribution tree is a separate, shortest path tree (SPT) built for each source originating traffic to the multicast group.
A rendezvous point is a specific router that is designated as the root of a shared multicast distribution tree. Each router in the network knows the identity of the rendezvous point for each multicast group because shared multicast distribution trees are rooted at the rendezvous points. An announcement protocol is typically used to select and announce rendezvous points to all routers in the network. However, an alternative to using an announcement protocol to automatically advertise rendezvous points to all routers in the network is to manually configure the identity of the rendezvous points on all of the routers. Examples of an announcement protocol include the Auto-RP multicast protocol available from Cisco Systems Inc. and the Bootstrap Router (BSR) described in Bootstrap Router (BSR) Mechanism for PIM Sparse Mode, Internet Engineering Task Force Internet-Draft, draft-ietf-pim-sm-bsr-03.txt, by Fenner, et al. February 2003. Examples of multicast routing protocols that use a rendezvous point include Protocol Independent Multicast-Sparse Mode (PIM-SM) and Bidirectional PIM (BIDIR-PIM) protocols. Other multicast protocols that do not require a rendezvous point include PIM dense mode (PIM-DM) and PIM source specific multicast (PIM-SSM) protocols.
IP multicast may be deployed on a computer network using a specific rendezvous point to build a shared multicast distribution tree for a specific group falling within a destination address prefix. Any group falling within a different prefix uses a different rendezvous point, i.e., a different group range-to-rendezvous point address mapping. A router joins a multicast group (distribution tree) towards the rendezvous point. The host (receiver) is a leaf or node on the distribution tree. Packets are sent from a source to the root of the distribution tree, where they are forwarded towards the branches and out to the nodes that represent the receivers. On each node, packets are received on the interface towards the root of the tree and packets are forwarded out other interfaces towards the receivers or nodes.
Specifically, a receiver uses IGMP to communicate a request to join a multicast group address to a last-hop router. The router communicates that request to its neighboring routers (neighbors) on the link towards the rendezvous point using a multicast routing protocol, such as PIM. Auto-RP or BSR is used to distribute group range-to-rendezvous point address mapping configuration to all PIM-enabled routers that participate in the network topology. Collectively the routers construct a shared multicast distribution tree rooted at the rendezvous point for that group address and having a branch that “pulls” data traffic towards the last-hop router.
The infrastructure of a router typically comprises functional components organized as a control plane and a data plane. The control plane includes the functional components needed to manage the traffic forwarding features of the router. These components include routing protocols, configuration information and other similar functions that determine the destinations of data packets based on information other than that contained within the packets. The data plane, on the other hand, includes functional components needed to perform forwarding operations for the packets.
For a single processor router, the control and data planes are typically implemented on the single processor. However, for some high performance routers, these planes are implemented within separate devices of the intermediate node. For example, the control plane may be implemented in a supervisor processor, whereas the data plane may be implemented within a hardware-assist device, such as a co-processor or a forwarding processor. In other words, the data plane is typically implemented in hardware that is separate from the hardware that implements the control plane.
The control plane generally tends to be more complex than the data plane in terms of the quality and quantity of software operating on the supervisor processor. Therefore, failures are more likely to occur in the supervisor processor when executing such complicated code. In order to ensure high availability in a router, it is desirable to configure the router such that if a failure arises with the control plane that requires restarting of software executing on the supervisor processor, the data plane continues to operate correctly. Restarting of control plane software may be necessary because of a failure with a routing protocol component or a software upgrade to that component. A router that is configured to enable its data plane to continue packet forwarding operations during restart of the control plane software is referred to as a non-stop forwarding (NSF) capable router.
Situations where a NSF capable router architecture is useful include both anticipated and non-anticipated failures in the control plane of the router. For example, failures in the control plane can include unanticipated or unplanned events (e.g., software crashes or hardware errors) as well as planned or anticipated events (e.g., scheduled maintenance). As for latter, assume it is desired to upgrade software running on the supervisor processor or even remove and replace that processor for service. Such an upgrade or removal/replacement may cause an interruption in one or more routing protocols, but the NSF nature of the router allows continued forwarding of data through the router.
NSF router architectures have been implemented in unicast forwarding applications to enhance router availability and avoid disruption of data connectivity. These previous implementations often require modification of unicast routing protocols to add support to NSF. For example, modifications to a known unicast routing protocol allow support for graceful restart of router protocol failures. When the router is restarted, the modified protocol allows the router to obtain information (via protocol message exchanges) with its neighbors and without the neighbors “viewing” the router as being completely down, thereby obviating any changes to the routing topology. The present invention is directed, in part, to implementing a multicast NSF router architecture without modifying existing multicast protocol definitions.
Failures or outages of hardware or software controlling a multicast router (i.e., components in the control plane, not in the path of data packets through the router) can cause multicast data packets transiting the router to be dropped without recourse. The result is loss of multicast connectivity in the network and decreased availability of the impacted router. The present invention is further directed to solving the loss of multicast data connectivity and decreased availability during control failures in a multicast router.